Processing for performing bank account deposits and transfers on-line may in practice, for example, consist of the sequence of procedures in which request messages are sent from terminals to a host, resources (in the present specification, "resources" is a general term for databases, files, memory tapes or the like) are accessed in the host and are processed, and answer messages are returned from the host to the terminals. These procedures as a whole constitute a single theoretical unit of on-line database processing, and this single theoretical unit is termed a "transaction".
A transaction changes the contents of the resources, but the content of the resources after this change must have a correct meaning from the point of view of the user. For this reason, a transaction must be either committed (completed) or aborted (completely not processed), but must not be left in a part way performed or fragmentary state.
Now, as one possibility for an on-line database processing system, there has been proposed a cooperative type distributed system in which a plurality of processing devices which are connected together by signal transmission circuits maintain a resource which is divided into sections, and cooperate so as to perform distributed processing of transactions. When this cooperative type distributed system is compared with a more usual system in which a single large sized mainframe computer performs centralized processing of the resources, it excels with regard to reduction of cost, dispersal of the risk of failure, and flexibility for increasing or decreasing the size of the system.
However, since with this type of distributed system a single transaction involves resource updating processing by a plurality of processing devices, it is necessary to ensure that the resource updating processing by this plurality of processing devices is consistent; in other words, that the situation does not arise in which, although a certain device has updated a resource with relation to a particular transaction, a different device has not performed such updating. The "two phase commit" method conceived of by N. J. Gray is known as a transaction processing method for this purpose.
With this "two phase commit" method, a transaction is separated into two phases: hypothetical updating and actual updating. When some terminal issues a request for a transaction, this request is received by a single processing device. In the initial hypothetical updating phase, this single processing device which has received the transaction (hereinafter termed the coordinator) inquires from the one or more processing devices (hereinafter termed the participant or devices) which maintain the database or databases to be updated whether such updating is possible or not, and responses are returned from these participants to the coordinator as to whether or not such updating is possible. As a result, the system only proceeds to the actual updating phase in the event that responses have been returned from all of the participants to the effect that such updating is possible. In this actual updating phase, commit commands are issued from the coordinator to all of the participants, and each of the participants which has received the commit command actually updates its corresponding resource; and thereafter updating completion messages are returned to the coordinator from each of the participants.
According to the procedure which these two phases described above constitute, the commit command is issued and the actual updating of the databases is performed only in the event that all of the processing devices which perform distributed processing for the transaction are able to update the resources.
However, there are some problems with this "two phase commit" procedure, as follows.
First, since signal interchange between the above described coordinator and participant or devices must be performed a minimum of four times, a signal transmission overhead is entailed the length of which cannot be ignored. As a result the overall speed of processing of the system is low.
Further, since transaction processing proceeds by the procedure being repeated of messages being dispatched as described above from the coordinator to the participant or devices, and by replies to these messages then being returned from the participant or devices to the coordinator, accordingly, if in the midst of transaction processing a blocking failure or the like occurs in any one of the processing devices, at this time point the processing by all the processing devices is stopped, which is undesirable. One method for solving this problem is to cancel the processing of any single transaction if it has been stopped for more than a fixed time period, and then to continue to the processing of the next transaction. However, the waiting for this fixed time period reduces the overall speed of processing of the system.
Furthermore, with the "two phase commit" procedure, stopping part way through or rolling back of the actual updating procedures for the other processing devices can no longer be performed in the actual updating phase after the commit command has been issued, even if one of the processing devices fails with the actual updating procedure. Therefore in this case the actual updating procedure is undesirably executed for the other processing devices, and as a result the consistency of the resource updating procedure is compromised.
This type of "two phase commit" procedure is not one which can perfectly satisfy the requirement for transaction processing to proceed accurately and smoothly.
Further, cooperative type distributed systems which have been known in the prior art, as well as being subject to the problems detailed above in connection with the "two phase commit" procedure, also have the following types of problem.
First, with prior art systems, the apportionment of duties as the master and participants is decided upon in a fixed manner among the plurality of processing devices. In other words, the flexibility of being able to alter the apportionment of duties of the plurality of processing devices according to circumstances is lacking.
Further, prior art systems are subject to the following problems even with regard to the procedure for storing (in other words, writing) a log entry in storage when a transaction is committed. As will be described hereinafter in detail, each of the various known log storage techniques is suitable either for times of high traffic or for times of low traffic, but none of them is suitable for both types of condition. Moreover, with prior art log storage techniques, the time period for storing a log entry for a single transaction is long.
Yet further, the problem arises with prior art systems that the processing time is long even for recovery of a resource after an error has occurred in that resource. The cause of this, as will be explained hereinafter in detail, is the combination of the fact that the burden of recovery processing is concentrated upon the single processing device which manages the resource which is to be recovered, the fact that the processing program for determining whether or not the resource has actually been updated is complicated, and the fact that referring to the log takes some considerable time.